Robust software library wrapper method and apparatus

ABSTRACT

A method includes a step of executing a software function using a set of test arguments and obtaining a result corresponding to each of the set of test arguments, each result indicating one of a set of robust and non-robust results, a subset of test arguments corresponding to robust results. The method further includes defining a set of arguments based on the results and the set of test arguments, the set of arguments including the subset of test arguments. Thereafter, arguments of subsequent calls to the software function may thereafter be examined to determine whether they fall within the set of arguments.

This application is a continuation of U.S. Ser. No. 10/441,533 filed May20, 2003, the contents of which are incorporated by reference herein.

FIELD OF THE INVENTION

The present invention relates generally to library software routinescalled by application software, and more particularly, to softwareroutines written in non-robust computer languages.

BACKGROUND OF THE INVENTION

Computer software may be written in any number of programming languages.Such languages include C, C++, Java, Cobol, ML and others. Increasingly,many software languages are robust, such as Java and ML, meaning thatthey operate in an environment so removed from the machine levelresources that an executed program cannot typically corrupt the hostmachine memory or crash the host machine. While robust languages provideprotection against host machine corruption and crashing, robustlanguages tend not to be particularly efficient.

By contrast, the C-family of languages, including C and C++(hereinafterreferred to as “C languages”), can be much more efficient, although notrobust. To this end, the C languages allow extensive access, control andmanipulation of host machine resources such as memory. As a consequence,C language programs can be prone to buffer overruns and other memorymisallocation errors that crash or hang the program.

Although C language programs lack the robustness of programs written inJava and other such languages, the need for efficiency in programminghas resulted in the continued extensive use of the C languages. Tocapitalize on the potential efficiencies, C language programmers attemptto optimize memory usage based on knowledge of the application beingwritten. For example, extensive control over memory also supportsmemory-mapped I/O, which is important for system level programming. Suchextensive control, however, increases the potential for memory misuseerrors, and even provides potential security issues.

While extreme care may be used to ensure that a particular C languageapplication does not misuse or improperly overwrite memory, a problemarises from the fact that nearly all C language programs incorporatestandard (or non-standard) library functions which are not written bythe application developer. In particular, as is known in the art, Clanguage development kits make available large numbers of commonfunctions in the form of libraries. For example, one library offunctions may include input/output oriented functions, while anotherlibrary includes string handling functions. Multiple libraries of suchfunctions are often “included” in application software.

The problem with standard library functions is that they may or may nothave had extensive testing to determine whether they are sufficientlyrobust so as to avoid crashing and security breaches. Accordingly,incorporation of standard C language library functions may make anotherwise robust software application prone to memory allocation errors.

While it is possible to develop software without using standard libraryfunctions, thereby allowing the developer absolute control therobustness of the application, such a scenario is impractical. The highlabor cost associated with software development does not reasonablyallow for each new application to recreate the same standard functions.Thus, the use of commercial off the shelf library C language functionsis a necessity.

Solutions have been proposed to overcome the problems posed by standardlibrary functions. Such solutions envision implementation of a softwarewrapper around certain C language functions. The wrappers interceptcalls to the function, and then determine whether any of the inputs tothe function was invalid. Descriptions of such wrappers may be found inFetzer, Christof and Xiao, Zhen “Detecting Heap Smashing Attacks ThroughFault Containment Wrappers”, Proceedings of the 20^(th) IEEE Symposiumon Reliable Distributed Systems (IEEE, October, 2001), which isincorporated herein by reference.

By intercepting function calls and determining if variables passed tothe function are invalid, the wrapper can prevent execution of thefunction if execution of the function with the passed variables couldcause a security breach or system failure. However, the development ofsuch wrappers for each function involves extensive modeling andanalysis. As a consequence, attempting to develop custom wrappers forthe multitude of functions in various libraries can be cost prohibitive.

Accordingly, there is a need for a method to ensure robust operation ofpotentially non-robust software libraries that does not suffer from thedrawback of requiring extensive modeling and analysis.

SUMMARY OF THE INVENTION

The present invention addresses the above need, as well as others, byproviding an at least partially automated method of generating robustargument types for library functions. The robust argument types may beused by a software wrapper to determine the validity of arguments in afunction call by application software to the library function. Thus, ifan application calls the library function using an argument that is nota robust argument type, then the wrapper returns an error and thefunction is not called. The at least partially automated process ofgenerating robust argument types helps make the process of developingsoftware wrappers for large libraries of functions practicable.

A first embodiment of the invention is a method that includes a step ofexecuting a software function using a set of test arguments andobtaining a result corresponding to each of the set of test arguments,each result indicating one of a set of robust and non-robust results, asubset of test arguments corresponding to robust results. The methodfurther includes defining a set of arguments based on the results andthe set of test arguments, the set of arguments including the subset oftest arguments. Thereafter, arguments of subsequent calls to thesoftware function may thereafter be examined to determine whether theyfall within the set of arguments.

Another embodiment of the invention is code, stored in a computerstorage device, that carries out the above steps.

The above described features and advantages, as well as others, willbecome more readily apparent by reference to the following detaileddescription and accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows a block diagram of an exemplary software architecture thatincorporates the present invention;

FIG. 2 shows a block diagram of an exemplary computing device thatincorporates aspects of the present invention;

FIG. 3 shows a flow diagram of an exemplary set of operations forgenerating a software wrapper in accordance with the present invention;

FIG. 4 shows a flow diagram of a first exemplary automated method ofgenerating fundamental robust argument types in accordance with theoperations of FIG. 3;

FIG. 5 shows a flow diagram of a second exemplary automated method ofgenerating fundamental robust argument types in accordance with theoperations of FIG. 3;

FIG. 6 shows a logic chart illustrating a first exemplary scheme forconverting fundamental argument types into final robust types inaccordance with the operations of FIG. 3;

FIG. 7 shows a logic chart illustrating a second exemplary scheme forconverting fundamental argument types into final robust types inaccordance with the operations of FIG. 3; and

FIG. 8 shows a diagram of memory allocated by the fault injector duringthe injection of a fixed size array of size N.

DETAILED DESCRIPTION

FIG. 1 illustrates an exemplary software architecture 100 thatincorporates wrappers generated in accordance with the presentinvention. In particular, FIG. 1 illustrates the run-time architectureof one or more user applications 102 and 104 that employ one or morefunctions of one or more shared libraries 106. A set of robustnesswrappers 108 generated in accordance with the present invention arelogically interposed between the user applications 102 and 104 and theshared libraries 106.

The software architecture 100 may be implemented in code executed by oneor more computing devices, such as the exemplary computing arrangementof FIG. 2. Referring to FIG. 2, the exemplary computing arrangement 200includes a processing circuit 202, a display 204, a set of input devices206, and storage elements 210. The computing arrangement 200 maysuitably be a single general purpose computer, such as a commerciallyavailable computer available from Dell Computer Corporation.Alternatively, the computing device 200 may also be implemented as aplurality of computing devices arranged in a local area network, anenterprise-wide network, or an internetwork.

The processing circuit 202 comprises one or more processing devices andrelated support circuitry. Multiple processing devices may be enclosedwithin a single general purpose computer or distributed over severalcomputers in a network setting. A processing device of the processingcircuit 202 may suitably comprise a Pentium® type microprocessoravailable from Intel Corporation.

The display 204 may be one or more suitable displays operable to givehuman-perceptible output. To this end, the display 204 may comprise aCRT display, an LCD display, a plasma display, or even a haptic display.The input devices 206 may comprises a plurality of devices operable toprovide user input to a computer, including alphanumeric keyboards andkeypads, mice, light pens, other pointing devices, and even microphones.The input devices 206 may also include communication interfacesconnected to other computing devices, not shown, but which are wellknown in the art.

The storage elements 210 include a variety of data storage devicesaccessible to the processing device, including random access memory,read-only memory, flash programmable memory, hard disk, removablecompact disk and floppy disk, tape devices and any combinations of theforegoing.

Referring FIG. 1 and FIG. 2, code for at least one of the userapplications 102, the robustness wrapper 108 and the shared libraries106 are suitably stored within the storage elements 210. If thecomputing arrangement 200 is implemented as a network, the code for theuser applications 102,104, the shared libraries 106 and the robustnesswrapper 106 may be distributed over multiple physical storage elements.Those of ordinary skill in the art may readily devise their ownimplementation details. Any suitable implementation of a shared (orunshared) C-library may be used, with the wrapper 106 implemented in amanner similar to the C-library.

In general, the user applications 102 and 104 may be any applicationsthat employ potentially non-robust functions from the shared library106. In general, the embodiment described herein uses a shared Clanguage library as the shared library 106, which contains C or C++programs. The functions of the shared library 106 are preferablycommercial off the shelf libraries such as, for example, the glibc2.2library available from RedHat Linux.

The robustness wrappers 108 are made of up one or more wrappers 108 a,108 b, etc., each wrapper 108 x is comprised of code configured to causethe processing circuit 202 to receive or intercept a function call to acorresponding library function from the shared libraries 106. Thefunction call will typically include at least one argument thatrepresents a value from the user application that is passed to thelibrary function for use during execution of the library function. Forexample, the function call asctime(tm) calls the function asctime fromthe glibc2.2 with the argument tm. The argument tm is a point er to thestructure that represents a current time value.

The robustness wrapper 108 x further includes code for determining ifthe argument(s) is(are) a robust argument type. A robust argument typeis a data structure that will not cause a robustness fault when used asan argument in a call to the library function. As discussed above, manylibrary functions are not completely robust, because if certainstructures are passed to the functions in the arguments, the functionwill crash, hang-up or write to an invalid portion of memory. Suchfaults are robustness faults. By contrast, if a library function merelyreturns an error, without crashing, hanging up or an improper memoryaccess, it is not necessarily a robustness fault. Those structures thatcould crash, hang-up or perform an invalid write are not robust argumenttypes. Only structures that do not cause such faults are considered tobe robust argument types.

The set of robust argument types is previously determined byautomatically injecting test data structures into the library functionto determine a set of data structure types that do not cause faults whenused as an argument passed to that function. Further detail regardingthe generation of robust argument types is provided below in connectionwith FIGS. 3 through 7.

The robustness wrapper 108 x further includes code for performing thelibrary function call if the argument(s) is(are) determined to be arobust argument type, and for returning an error notification if theargument is not a robust argument type. Thus, each robustness wrapper108 x operates to inhibit calling a function using a non-robust argumenttype.

In accordance with one aspect of the invention, each robustness wrapper108 x is at least partially automatically generated using faultinjection to determine the robust argument types. FIG. 3 described belowprovides an exemplary set of steps in which a robustness wrapper such asthe robustness wrappers 108 a and 108 b may be generated.

Referring to FIG. 3, there is shown a general robustness wrappergeneration method that may be used to generate robustness wrappers foreach library of functions. Within FIG. 3, steps 304-308 operate tocompute the robust argument types for an individual function, which isrepeated for each library function of the shared library. The result isused in step 310 to generate a robustness wrapper for library functionsthat may be directly called by a user application.

In general, the operations of FIG. 3, as well as FIGS. 4-7, may becarried out at least in part by one or more processors usingcorresponding code stored in a storage element. The processor may be aprocessor within the processing circuit 202, using code stored in one ormore storage elements, such as the storage elements 210 of FIG. 2.However, it will be appreciated that the processor and storage elementsused to carry out the operations of FIGS. 3 to 7 may be disposed in adifferent computing device than the computing arrangement that performsthe operations described above in connection with FIG. 1. However, suchother computing device would have the same general architecture as thatdiscussed above in connection with FIG. 2.

Referring again to FIG. 3, in step 302, a list of functions is obtainedfor the library being wrapped. In general, a robustness wrapper needonly be generated in C-libraries for those functions that may be calleddirectly from a user application. Most C-libraries adopt the conventionthat all names beginning with an underscore, e.g. _IO_flush, denoteinternal functions that are not to be used by applications. Accordingly,step 302 may be automated by employing the processor to parse adirectory of functions in the library and obtain a list of functionsthat do not begin with an underscore.

Once the list of functions to be wrapped has been obtained, steps 304through 308 are executed for each function on the list.

In step 304, the argument or arguments for the function are determined.In particular, the “types” of any arguments employed in library functioncall are identified. In general, one may determine the types ofarguments for a function from text descriptions of the libraryfunctions. Indeed, all library functions must have some descriptions orapplication developers would not be able to use the functions.

The determination of argument types may be automated in C++ librarieswherein the function name and argument type are encoded in eachfunction's symbol name. Accordingly, for C++ libraries, the processormay be programmed to extract the function name and type information fromthe symbol name of each function.

In ordinary C libraries, the operation may be partially automated byparsing header files that contain the prototypes of the globalfunctions. Unfortunately, however, many C libraries do not include awell-defined set of header files that describe the interface of theshared library. To determine the proper set of header files that containthe prototypes of the function, the on-line text manual page thatdescribes the function may be parsed. By convention, manual pagescontain a list of all header files that need to be included by a programthat wants to use the function. Thus the processor could be programmedto parse out the function argument type information from the manualpage. If a function has no manual page, the processor may search throughall of the header files in the library to locate the prototype of thefunction.

In step 306, the fundamental robust types for the function areidentified. A type is a characterization of a data structure, variable,or pointer. For example, common C types include float, int, andpointers. A robust type is a data type that does not cause the functionunder test to exhibit a robustness fault. In the embodiment describedherein, robust types are specially-defined subsets of the standard Ctypes. As discussed above, the wrapper determines whether an argument ina function call is a robust argument type, or in other words, within thespecially-defined subset of C types that does not cause a robustnessfault. A fundamental robust type is a generic basic building block whichmay be combined with other fundamental robust types to form a singleunified robust type.

In the embodiment described herein, the processor determines thefundamental robust types by performing a partially predetermined set offault injection tests. The set of fault injection tests corresponds tothe argument type expected for the function. Thus, if the argument typeof the library function is a fixed array pointer, then a particular setof fault injection tests is performed that correspond to fixed arraypointers. FIG. 4, for example, shows an exemplary flow diagram ofinjection tests performed for function having a fixed array pointer typeargument.

In general, each argument type is divided into a set of fundamentaltypes. The fundamental types are non-overlapping, but should as a grouprepresent most or all possible data structures associated with anargument type. FIGS. 3 and 5 discuss the fundamental types for fixedarray pointers. FIGS. 4 and 6 discuss the fundamental types for filepointers.

The set of fault injection tests are configured to determine whethereach of the set of fundamental types corresponding to the argument typeis robust or is not robust. To this end, the set of fault injectiontests injects various fundamental types as arguments to determinewhether they cause a robustness fault. Specific examples of faultinjection tests for such fundamental types are provided in connectionwith FIGS. 4 and 5.

Thus, fault injection test sequences are developed for multiple genericargument types. Accordingly, step 306 may be automated by employing theprocessor to execute the test sequence for the argument type or typesfor the specified function. For example, if the processor determines instep 304 that the function has a fixed array type argument, theprocessor performs the test sequence shown in FIG. 4 and discussedbelow. However, if the processor determines in step 304 that thefunction has a different type argument then a different test sequence isperformed.

In step 308, a robust type for the function is determined from the oneor more fundamental robust types determined in step 306. In particular,if multiple fundamental robust types are determined in step 306, thenthe fundamental robust types are combined into a superset of types thatdo not cause robustness faults. To this end, an at least partiallypredetermined group of robust types are defined for possiblecombinations of robust function types. Thus, a predetermined set ofrules is available to dictate how the fundamental robust types may becombined.

By way of example, FIG. 7 shows a chart illustrating the combinationrules for fundamental types associated with for file pointer argumenttypes. The chart shows all of the relevant fundamental types, hereillustrated as RONLY_FILE, WONLY_FILE, RW_FILE and NULL. After step 306,all or some of those fundamental types have been determined to be robustfundamental types. To determine the robust type from the robustfundamental types, the chart is traversed upward from the robustfundamental types until the next upward combined type would include anon-robust type. A non-robust type is (or includes) a fundamental typefor which at least one argument will cause a robustness fault of thefunction, as determined in step 306.

Thus, by way of example, if fault injection tests using “write only”file pointers and null pointers result in robustness failures (e.g. abuffer overrun faults), but no fault injection tests for “read only” or“read/write” files result in robustness faults, then the robustfundamental types would only be the RONLY_FILE and RW_FILE fundamentaltypes. The WONLY_FILE fundamental type is not robust. The only upwardlylocated robust type on the chart of FIG. 7 that does not includeWONLY_FILE or NULL is R_FILE. Thus, step 308 in such a case woulddetermine R_FILE to be the highest robust type. In general R_FILErepresents any file that can be read, including read only andread-writable files.

FIG. 6 shows another example of a chart defining the operation ofdetermining a robust type from one or more fundamental robust types.FIG. 6 shows a chart used for functions having fixed array pointerarguments.

Referring again to FIG. 3, step 308 may be automated by programming theprocessor to execute the rules illustrated in the charts of FIGS. 6 and7, as well as other analogous charts corresponding to other genericargument types. The result of step 308 in any event is a robust typedefinition for the function. Thus, if the library function is calledwith an argument that falls within the definition of the robust type,the function call will not cause a robustness fault, such as a hang-up,an invalid overwrite to memory, or a crash.

It will be appreciated that the robust type definition determined instep 308 may include both a type element and a size element. A typeelement defines a characteristic of the memory block allocated to arobust argument, such as “read-only”, “write-only”, “readable”, or“writeable and null”. (See e.g. FIGS. 6 and 7). A size element definesthe quantity of memory that must be allocated to the argument, if any,in order to be robust. For example, a robust type for a fixed arrayargument may require 44 bytes of allocated memory.

An example of robust types having both a type element and a size elementare discussed below in connection with FIGS. 4 and 6. It is noted thatother robust type definitions do not include a size element. An exampleof robust types having only a type element are discussed below inconnection with FIGS. 5 and 7. The determination of whether a particularrobust type should include a size element will depend upon whether aparticular argument type is of the sort that may have a selectablememory allocation, such as a fixed array.

In any event, once the robust type has been identified for the libraryfunction, step 310 is executed. In step 310, the robustness wrapper codeitself is generated. To this end, the function name and the dataacquired in steps 304, 306 and 308 is applied to a software shell. Anexemplary shell is provided below:  char* functionname(const struct tm*argument  / intercepts call to functionname  / with argument   char* ret/ declares return value pointer   if(in_flag) { / check if alreadywrapper    return (*libc_functionname) (argument);  / if already inwrapper, go ahead  / and skip the check   }   in_flag = 1;  / set “inwrapper” flag   if (!check_robtype(argument,robsize)) / call checkingfunction for robust  / type determined in step 308,  / robtypeidentifies the type  / element and robsize is the size  / element of therobust type.  / Some robust types have no  / size elements. The “If”  /statement acts on the result  / of !check_robtype: If argument  / is notrobust type,  / then perform bracketed steps    {   ret = (char*) NULL;/ return error signifier NULL / to original function call because /argument is not robust type   goto PostProcessing; / skip ahead    }  ret = (*libc_functionname)(argument)  / perform original function  /with argument and save  / return value as ret.  / this is performed whenIf  / statement is false because  / argument is a robust type  PostProcessing   in_flag = 0 ;  / turn off flag to leave   return ret; / provide ret value to user  / application   }

To generate the final wrapper code from the above shell, thefunctionname, the robtype and robsize (if any), are obtained from theinformation generated in steps 304-308. For example, the functionname isthe name of the library function, robtype is the type element of therobust type determined in step 308, and robsize is the size element ofthe robust type definition.

A “check” function is developed for each type element of each robusttype definition. If a size element is included in the robust typedefinition, it is passed as an argument to the “check” function for theappropriate robust type type element. Each check function determines 1)if the memory or buffer allocated to the pointer being passed to thefunction is of the corresponding type (readable, writeable, null, etc.)and 2) if the memory or buffer allocated to the pointer or variablebeing passed to the function has sufficient memory allocated to it.

The check functions for all of the potential robust types arepre-developed, and several methods may be used to generate suitablecheck functions. One method involves tracking variable and pointerdeclarations during the user application run time so that when afunction is called with a variable or pointer declaration, the wrapperknows details regarding its type and size. To implement such a methodthe wrapper library may include a function that intercepts all malloccalls and tracks the memory allocated to each pointer or variable as aresult of the malloc calls.

Further detail regarding generating argument checking functions isprovided in Christof Fetzer and Zhen Xiao, “Detecting Heap SmashingAttacks Through Fault Containment Wrappers”, Proceedings of the 20^(th)IEEE Symposium on Reliable Distribution Systems, (October, 2001), whichis incorporated herein by reference, and Frederic Salles et al.,“Metakernels and Fault Containment Wrappers”, discussed further above.

FIG. 4 shows an example of a fault injection test sequence that may beused for library functions that are determined to have arguments thatare fixed array pointers. Library functions having fixed array pointerarguments can be particularly prone to robustness faults because thelibrary function may attempt to write too much data to the memoryallocated to the array. In such a case, a computer crash or even asecurity breach can occur. Moreover, certain library functions may failif a pointer to “write-only” or “read-only” memory is passed to thefunction.

Accordingly, the robust type definition operation of the presentinvention determines which allocated memory types and allocated memorysize will not result in a robustness fault.

As mentioned above, FIG. 6 shows a chart that defines the possiblerobust types for a fixed size array, including the possible fundamentalrobust types, RONLY_FIXED[v], RW_FIXED[v], WONLY_FIXED[v], NULL, andINVALID, wherein v represents the size element of the type. Thefundamental type RONLY_FIXED[v] represents all fixed arrays that areread-only and require at least v bytes of allocated space. Thefundamental type RW_FIXED[v] represents all fixed arrays that areread-writeable and require at least v bytes of allocated space. Thefundamental type WONLY_FIXED[v] represents all fixed arrays that arewrite-only and require at least v bytes of allocated space. Thefundamental type NULL represents a null pointer and the fundamental typeINVALID represents a pointer to an inaccessible memory region. It isnoted that some library functions have a limited amount of inherentrobustness and therefore may be able to successfully handle a null orinvalid pointer. As a consequence, null pointers and invalid pointerscan be robust fundamental types, even though they can result in anerror.

Referring again to FIG. 4, the operations shown therein describe a testsequence employed for functions having a fixed array argument. The stepsof FIG. 4 may be performed by any suitable processor. The instructionsfor carrying out the steps of FIG. 4 may be stored as code in anysuitable memory device or devices.

In step 402, a counter N is set to zero. The counter N represents thesize of the allocated block of memory that is to be injected into to alibrary function. After step 402, the processor executes step 404.

In step 404, the processor injects a read-only array having an allocatedsize of N bytes into the library function to determine if theRONLY_FIXED[N] is a robust type. Because the counter N starts at zero,the first pointer that is injected is a zero-size array. One purpose ofthe injection is to determine if the library function attempts to writedata beyond the N-sized block of memory allocated to the array. Anotherpurpose of the injection is to determine whether the library functioncan handle read-only, write-only or read-write files without arobustness fault.

To this end, the processor generates a child process that calls thelibrary function using the pointer to the N-sized read-only array.Referring to FIG. 8, the child process first allocates two adjacentmemory pages 802 and 804, the memory page 802 having a starting addressof firstpage and an ending address at secondpage—1. The memory page 804has a starting address at secondpage and is protected to prohibit anyread or write access. The child process then allocates the memory to theN-sized read-only array, by allocating a block 806 of N bytes startingat the address secondpage-N.

As a consequence, if too little space is allocated, the child processcommits a buffer overrun error that corrupts (or attempts to corrupt)the available second page 804. Because the second page 804 is memoryprotected, it will generate a signal that allows the child process todetect that a buffer overrun has occurred. If, however, sufficient spacehas been allocated, then the child process does not generate a bufferoverrun error. In addition, the child process may crash, hang-up orreturn a buffer overrun if the library function cannot handle aread-only array in a robust manner. Even if the child process hangs upor crashes, the parent process (the operations of FIG. 4) will continue,with the knowledge that some robustness fault occurred.

Referring again to FIG. 4, once the test pointer RONLY_FIXED[N] has beeninjected and results obtained, then the processor executes step 406. Instep 406, the processor determines whether a robustness fault hasoccurred. A robustness fault is a buffer overrun or other fault (i.e.crash or hang) that is not handled by the library function itself. It isnoted that if the library function adequately handles an improper inputwithout a buffer overrun, crash, hang or other unsafe condition, even ifit returns an error value, then that argument is nevertheless consideredto be robust. Thus, the processor 406 determines whether a robustnessfault has occurred, not simply whether an error was detected.

If it is determined in step 406 that a robustness fault has occurred,then the processor executes step 408. In step 408, the processordetermines whether the fault occurred at the address beyond the lastaddress allocated to the array RONLY_FIXED[N]. In particular, theprocessor determines whether a “buffer overrun” error occurred, and ifthat error occurred at the address secondpage. If so, then it is anindication that the library function cannot handle arrays of size N in arobust manner. In such a case, the processor increases N in step 410 andreturns to step 404 to proceed accordingly. If not, however, then it isan indication that the failure was due to the fact that the libraryfunction cannot generally handle read-only arrays in a robust manner. Insuch a case, the processor proceeds to step 412 in which the processoridentifies RONLY_FIXED[N] as an invalid or non-robust type, regardlessof the size N.

Referring again to step 406, if it is determined that no robustnessfault was detected after injecting RONLY_FIXED[N] in step 404, then itis an indication that the library function can handle read-only arraysof size N in a robust manner. In general, if the library function canhandle arrays of a size N in a robust manner, then the library functioncan handle larger arrays (≧N) in a robust manner. In other words, if thelibrary function does not create a buffer overrun with an array having Nbytes allocated to it, then the library function will not create abuffer overrun with an array having more than N bytes allocated to it.Thus, if it is determined in step 406 that no robustness fault wasdetected, the processor executes step 414 in which it is determined thatRONLY_FIXED[≧N] is a robust fundamental type.

After either of steps 412 or 414, the processor executes step 418.

In step 418, the block size value N is reset to zero. After step 418,the processor executes step 420. In step 420, the processor injects aread-writeable array having an allocated size N into the libraryfunction to determine if the RW_FIXED[N] is a robust type.

Similar to step 404, the processor in step 420 generates a child processthat calls the library function using the pointer to the N-sizedread-writeable array. As with step 404, the child process firstidentifies two adjacent available memory pages 802 and 804, the memorypage 802 having a starting address of firstpage and an ending address atsecondpage—1. The memory page 804 has a starting address at secondpage.The child process then allocates the memory to the N-sizedread-writeable array by allocating a block 806 of N bytes starting atthe address secondpage-N.

Referring again to FIG. 4, once the test pointer RW_FIXED[N] has beeninjected and results obtained, then the processor executes step 422. Instep 422, the processor determines whether a robustness fault hasoccurred.

If it is determined in step 422 that a robustness fault has occurred,then the processor executed step 424. In step 424, the processordetermines whether the fault occurred at the address beyond the lastaddress allocated to the injected array. In particular, the processordetermines whether a “buffer overrun” error occurred, and if that erroroccurred at the address secondpage. If so, then the library functioncannot handle arrays of size N in a robust manner. In such a case, theprocessor increases N in step 426 and returns to step 420 to proceedaccordingly. If not, however, then the failure is likely due to the factthat the library function cannot generally handle read-writeable arraysin a robust manner. In such a case, the processor proceeds to step 428in which the processor identifies RW_FIXED[N] as an invalid ornon-robust type, regardless of the size N.

Referring again to step 422, if it is determined that no robustnessfault was detected after injecting RW_FIXED[N] in step 420, then thelibrary function can handle read-writeable arrays of size N or greaterin a robust manner. In such a case, the processor executes step 430 inwhich it is determined that RW_FIXED[≧N] is a robust fundamental type.

After either of steps 428 or 430, the processor executes step 432.

In step 432, the block size value N is reset to zero. After step 432,the processor executes step 434. In step 434, the processor injects awrite-only array having an allocated size of N bytes into the libraryfunction to determine if the WONLY_FIXED[N] is a robust type.

Similar to steps 404 and 420, the processor in step 434 generates achild process that calls the library function using the pointer to theN-sized write-only array. Referring to FIG. 8, the child process firstidentifies two adjacent available memory pages 802 and 804, the memorypage 802 having a starting address of firstpage and an ending address atsecondpage—1. The memory page 804 has a starting address at secondpage.The child process then allocates the memory to the N-sizedread-writeable array by allocating a block 806 of N bytes starting atthe address secondpage-N.

Referring again to FIG. 4, once the test pointer WONLY_FIXED[N] has beeninjected and results obtained, then the processor executes step 436. Instep 436, the processor determines whether a robustness fault hasoccurred.

If it is determined in step 436 that a robustness fault has occurred,then the processor executed step 438. In step 438, the processordetermines whether the fault occurred at the address beyond the lastaddress allocated to the injected array. In particular, the processordetermines whether a “buffer overrun” error occurred, and if that erroroccurred at the address secondpage. If so, then the library functioncannot handle arrays of size N in a robust manner. In such a case, theprocessor increases N in step 440 and returns to step 434 to proceedaccordingly. If not, however, then the library function cannot generallyhandle write-only arrays in a robust manner. In such a case, theprocessor proceeds to step 442 in which the processor identifiesWONLY_FIXED[N] as an invalid or non-robust type, regardless of the sizeN.

Referring again to step 436, if it is determined that no robustnessfault was detected after injecting WONLY_FIXED[N] in step 434, then thelibrary function can handle write-only arrays of size N or greater in arobust manner. In such a case, the processor executes step 444 in whichit is determined that WONLY_FIXED[≧N] is a robust fundamental type.

Thereafter, in step 446, the processor determines whether NULL andINVALID are robust fundamental types. In particular, the processorinjects a null pointer into the library function and determines whethera robustness fault occurs. If not, then NULL is determined to be arobust fundamental type. The processor further injects a pointer toinaccessible memory to the library function and determines whether arobustness fault occurs. If not, then INVALID is determined to be robustfundamental type. Note that NULL and INVALID types do not have a sizeelement.

Thus, upon conclusion of step 446, all of the fundamental types for afunction having a fixed array pointer argument have been determinedthrough a partially predetermined set of injection cases. The set oftests is said to be partially predetermined because the fault injectionsequence can be iterative, testing increasing array sizes until findinga size at which no error occurs.

The above-described operations of FIG. 4 provide one example of step 306of FIG. 3. Referring to FIG. 6, the fundamental types determined in FIG.4 may be combined using the chart of FIG. 6. To this end, the processordetermines the largest superset of fundamental robust types in the chartof FIG. 6. The determined superset does not include any non-robusttypes.

By way of example, consider an operation of FIG. 4 in which it isdetermined that the fundamental robust types are RONLY_FIXED[≧44],RW_FIXED[≧44] and NULL. Referring to the chart of FIG. 6, suchfundamental types can be combined to the highest supersetR_ARRAY_NULL[>44], which basically includes any array that can be read(either read-only or read-writeable), and has allocated to it at least44 bytes, ora null pointer.

Thus, operation of step 308 of FIG. 3 would yield R_ARRAY_NULL[≧44] insuch an example. Taking the example further, assume that the libraryfunction name in the example is asctime, which is known to have a fixedarray pointer argument. In such a case, in step 310, the followingwrapper code would be generated:   char* asctime(const struct tm* a1) /intercepts call to asctime / with argument a1    char* ret / declaresreturn value pointer    if(in_flag) { / check if already in wrapper    return (*libc_asctime) (a1); / if already in wrapper, go ahead /skip the check and call asctime    }    in_flag = 1; / set “in wrapper”flag    if (!check_R_ARRAY_NULL(a1, 44)) / call checking function forrobust / type determined in step 308. The / “If” statement acts on theresult of / !check_R_ARRAY_NULL: / If a1 is not robust type, / thenperform bracketed steps    {     ret = (char*) NULL;  / return errorsignifier NULL  / to original function call because  / a1 is not robusttype     goto PostProcessing;  / skip ahead    }    ret =(*libc_asctime)(a1)  / perform original function with  / a1 and savereturn value as ret.  / this is performed when If statement  / is falsebecause a1 is a robust type    PostProcessing    in_flag = 0 ;  / turnoff flag to leave    return ret;  / provide ret value to user  /application   }

FIG. 5 shows an example of a fault injection test set that may be usedin library functions that are determined to have arguments that are filepointers. Library functions may not be robust with regard to certaintypes of file pointers, for example, pointer to read-only files.Fundamental types for file pointers do not have a size element.

In particular, FIG. 7 shows a chart that defines the possible robusttypes for a file pointer that is an argument to a library function. Thepossible fundamental robust types include RONLY_FILE, RW_FILE,WONLY_FILE, and NULL. The fundamental type RONLY_FILE represents allfile pointers that point to read-only files. The fundamental typeRW_FILE represents all file pointers that point to read-writeable files.The fundamental type WONLY_FILE represents all file pointers that pointto write-only files. The fundamental type NULL represents a nullpointer.

Referring again to FIG. 5, the operations shown therein describe a testsequence employed for functions having a file pointer argument. Thesteps of FIG. 5 may be performed by any suitable processor. Theinstructions for carrying out the steps of FIG. 5 may be stored as codein any suitable memory device or devices.

In step 502, a counter N is set to one. The counter N represents anindex to the Nth of a number of different sized test files for aparticular file pointer format. After step 502, the processor executesstep 504.

In step 504, the processor injects the Nth read-only file pointer intothe library function. In the exemplary embodiment described herein,pointers to five different-sized read-only files must be successfullyinjected into the library function before read-only file pointers willbe considered to be robust. The use of multiple read-only test filesallows the process to determine that the library function may robustlyhandle files of various sizes. It will be appreciated that more or lessthan five test files may be used in step 504.

Referring again to the exemplary embodiment described herein, eachexecution of step 504 injects a pointer to one of the five test files.The five test file sizes should range from relatively small torelatively large, which in current terms may suitably range from anempty file to a one megabyte file. Thus, when N=1, then the processor instep 504 injects a pointer to an empty read-only file, when N=2, thenthe processor in step 504 injects a pointer to a read-only file of, say,32 bytes, and so forth, until N=5, at which time the processor in step504 injects a pointer to a read-only file of one megabyte.

In any event, the processor generates a child process that calls thelibrary function using the pointer to the N^(th) test file. The childprocess may crash, hang-up or otherwise act destructively if the libraryfunction cannot handle the Nth read-only file pointer in a robustmanner. Even if the child process hangs up or crashes, the parentprocess (the operations of FIG. 4) will continue, with the knowledgethat some robustness fault has occurred.

Once the N^(th) RONLY_FILE pointer has been injected and resultsobtained, then the processor executes step 506. In step 506, theprocessor determines whether a robustness fault has occurred.

If it is determined in step 506 that a robustness fault has occurred,then the processor executes step 508. In step 508, the processordetermines that RONLY_FILE is not a fundamental robust type. Thus, ifinjection of any of the RONLY_FILE file pointers causes a robustnesserror, then RONLY_FILE is not a robust type. After step 508, theprocessor proceeds to begin testing RW_FILE pointers in step 516.

If, however, it is determined in step 506 that no robustness fault hasoccurred, then the processor executes step 510. In step 510, theprocessor determines whether N=5. If not, then the processor in step 512increases N and returns to step 504 to inject the next read-only filepointer. If, however, N=5, then the processor proceeds to step 514.

In step 514, the processor determines that RONLY_FILE is a valid orrobust type. The processor thereafter proceeds to step 516 to testRW_FILE pointers.

In step 516, a counter N is reset to one. After step 516, the processorexecutes step 518. In step 518, the processor injects the N^(th)read-writeable file pointer into the library function. As with theread-only files, pointers to five different-sized read-writeable filesmust be injected into the library function before read-writeable filepointers will be considered to be robust. Each execution of step 518injects a pointer to one of those five test files. The five test filesizes should have a range similar to that of the read-only filesdiscussed above in connection with step 504.

Once the N^(th) RW_FILE pointer has been injected and results obtained,then the processor executes step 520. In step 520, the processordetermines whether a robustness fault has occurred.

If it is determined in step 520 that a robustness fault has occurred,then the processor executes step 522. In step 522, the processordetermines that RW_FILE is not a fundamental robust type. After step522, the processor proceeds to begin testing WONLY_FILE pointers in step530.

If, however, it is determined in step 520 that no robustness fault hasoccurred, then the processor executes step 524. In step 524, theprocessor determines whether N=5. If not, then the processor in step 526increases N and returns to step 520 to inject the next read-writeablefile pointer. If, however, N=5, then the processor proceeds to step 528.

In step 528, the processor determines that RW_FILE is a valid or robusttype. The processor thereafter proceeds to step 530 to test WONLY_FILEpointers.

In step 530, a counter N is reset to one. After step 530, the processorexecutes step 530. In step 532, the processor injects the N^(th)write-only file pointer into the library function. As with the otherfiles pointer, pointers to five different-sized write-only files must beinjected into the library function to ensure that write-only filepointers are robust. Each execution of step 532 injects a pointer to oneof those five files. The five sizes should have a range similar to thatof the read-only files discussed above in connection with step 504.

Once the N^(th) WONLY_FILE pointer has been injected and resultsobtained, then the processor executes step 534. In step 534, theprocessor determines whether a robustness fault has occurred.

If it is determined in step 534 that a robustness fault has occurred,then the processor executes step 536. In step 536, the processordetermines that WONLY_FILE is not a fundamental robust type. After step536, the processor proceeds to step 544.

If, however, it is determined in step 534 that no robustness fault hasoccurred, then the processor executes step 538. In step 538, theprocessor determines whether N=5. If not, then the processor in step 540increases N and returns to step 534 to inject the next write-only filepointer. If, however, N=5, then the processor proceeds to step 542.

In step 542, the processor determines that WONLY_FILE is a valid orrobust type. The processor thereafter proceeds to step 544.

In step 544, the processor determines whether NULL is a robust type byinjecting a null pointer into the library function.

The above-described operations of FIG. 5 provide another example of step306 of FIG. 3. The robust fundamental types would then be used togenerate a robust type in step 308. To this end, the fundamental typesdetermined in FIG. 5 may be combined using the chart of FIG. 7. Inparticular, the processor determines the largest superset of fundamentalrobust types in the chart of FIG. 7. The determined superset does notinclude any non-robust types. The resulting superset constitutes therobust type that may be used in the generation of the wrapper for thelibrary function.

Referring again generally to FIG. 3, it can be seen that a good portionof the wrapper generating operations may be automated, thereby makingthe generation of wrappers for large libraries of functions manageable.

The above-described embodiments are generalized for handling a singleargument of a function. For n-ary functions (having n arguments), thecomputation of robust argument types can be generalized as follows.N-dimensional type vectors are defined such that the i-th element of avector is the type of the i-th argument of the function. The partialorder over types (e.g. FIGS. 6 and 7) defines a partial order over thetype vectors. In particular, it introduces the notion of supersets fortype vectors. Each function call by the fault-injection test sequence(e.g. step 404) consists of n test cases (referred to as a test casevector) and these uniquely define a type vector consisting offundamental types. The value set V(TV) of a type vector TV consists of aset of value vectors that is uniquely defined by the value set of the ntypes.

The definition of a robust type vectors can be generalized as follows. Arobust type vector of a function is the type vector TV such that alltest case vectors for which the function does not exhibit a robustnessfault are in V(TV) and none of the test case vectors for which thefunction exhibits a robustness fault is in V(TV). We call the i-thelement of TV the robust type of argument i.

Accordingly, the principles described above in connection with FIGS. 1-7may readily be implemented in functions having multiple arguments.

The above-described embodiments are merely exemplary, and those ofordinary skill in the art may readily devise their own implementationsand modifications that incorporate the principles of the presentinvention and fall within the spirit and scope thereof. It will beappreciated that the term “C” as used herein is used to genericallydescribed “C” or “C++” attributes, unless otherwise indicated.

1. A method, comprising: a) executing a software function using a set oftest arguments and obtaining a result corresponding to each of the setof test arguments, each result indicating one of a set of non-robust androbust results, a subset of test arguments corresponding to robustresults; and b) defining a set of arguments based on the results and theset of test arguments, the set of arguments including the subset of testarguments.
 2. The method of claim 1, wherein no result indicates anon-robust result.
 3. The method of claim 1, wherein at least one resultindicates a non-robust result, the at least one result corresponding toa first invalid argument, and wherein the set of arguments does notinclude the first invalid argument.
 4. The method of claim 1, whereinstep a) further comprises: a1) executing the software function using aplurality of types of test arguments and obtaining a resultcorresponding to each of the test arguments, each result indicating oneof a set of robust and non-robust results; a2) determining at least onesubset of valid test arguments, each corresponding to one of theplurality of types of test arguments, the at least one subset of validtest arguments constituting the subset of test arguments correspondingto robust results.
 5. The method of claim 4, wherein step b) furthercomprises combining a plurality of subsets of valid test arguments toform the set of arguments.
 6. The method of claim 1, further comprising:d) determining if an argument associated with a subsequent call toexecute the software function is in the set of arguments.
 7. The methodof claim 6, further comprising: e) returning an error value if theargument is not one the set of arguments.
 8. The method of claim 7,further comprising: e) allowing execution of the software function usingthe argument if the argument is one of the set of arguments.
 9. Themethod of claim 1, further comprising: c) automatically generating awrapper function that is executable upon a subsequent call to thesoftware function, the wrapper function operable to determine if anargument within the subsequent call to the software function is in theset of arguments.
 10. The method of claim 9, wherein the wrapperfunction is further operable to perform a call to the software functionif the argument within the subsequent call is in the set of arguments.11. The method of claim 9, wherein the first wrapper function is furtheroperable to prevent execution of the software function responsive to thesubsequent call if the argument within the subsequent call is not in theset of arguments.
 12. A method of performing a library function call inan execution of a software program, the method comprising: receiving afunction call to a library function using at least one argument; anddetermining if the at least one argument is a robust argument type, aset of robust argument types previously determined by automaticallyinjecting test arguments into the library function to determine a set ofargument types that do not cause robustness errors when used as anargument passed to the library function.
 13. The method of claim 12,further comprising: performing the function call if the at least oneargument is a robust argument type; and returning an error notificationif the first argument is not a robust argument type.
 14. The method ofclaim 12, wherein receiving the function call further comprisesreceiving the function call to a first C-library function.
 15. Acomputer program product that controls a processor to perform a method,the computer program product comprising: code for executing a softwarefunction using a set of test arguments and obtaining a resultcorresponding to each of the set of test arguments, each resultindicating one of a set of robust and non-robust results, a subset oftest arguments corresponding to robust results; and code for defining aset of arguments based on the results and the set of test arguments, theset of arguments including the subset of test arguments.
 16. Thecomputer program product of claim 15, wherein the code for executing thesoftware function using the set of test arguments further comprises:code for causing execution of the software function using a plurality oftypes of test arguments and obtaining a result corresponding to each ofthe test arguments, each result indicating one of a set of robust andnon-robust results; and code for determining at least one subset ofvalid test arguments, each corresponding to one of the plurality oftypes of test arguments, the at least one subset of valid test argumentsconstituting the first subset of test arguments corresponding to robustresults.
 17. The computer program product of claim 16, wherein the codefor defining the set of arguments further comprises code for combining aplurality of subsets of valid test arguments to form the set ofarguments.
 18. The computer program product of claim 15, furthercomprising: code for determining if an argument associated with asubsequent call to execute the software function is one of the set ofarguments.
 19. The computer program product of claim 18, furthercomprising: code for returning an error value if the argument is not oneof the set of arguments.
 20. The computer program product of claim 18,further comprising: code for causing execution of the software functionusing the argument if the argument is one of the set of arguments. 21.The computer program product of claim 15, further comprising: code forautomatically generating a wrapper function that is executable upon asubsequent call to the software function, the wrapper function operableto determine if one or more arguments within the subsequent call to thesoftware function are in the set of arguments.
 22. The computer programproduct of claim 21, wherein the wrapper function is further operable toperform a call to the software function if the one or more argumentswithin the subsequent call are in the set of arguments.
 23. The computerprogram product of claim 21, wherein the first wrapper function isfurther operable to prevent execution of the software functionresponsive to the subsequent call if the one or more arguments withinthe subsequent call are not in the set of arguments.
 24. A method forincreasing the robustness of software libraries, comprising: a)automatically extracting the prototype of at least one library function;b) constructing a fault-injection operation for the at least one libraryfunction based on the extracted prototype; c) conducting thefault-injection operation to determine robustness errors for the atleast one library function; and d) computing the robust argument typesfor the at least one library function, wherein execution of the at leastone library function with an argument that is one of said robustargument types reduces the likelihood of robustness errors.
 25. Themethod of claim 24, further comprising extracting the prototype of theat least one library function a header file for the at least one libraryfunction.
 26. The method of claim 24, further comprising using thegenerated robust argument types to check the function call from anexecuting program to the at least one library function.